1. Field of the Invention
The present invention relates to a simulation system, a simulation evaluation system, a simulation method, and a computer-readable memory containing a simulation program, and more particularly to a technique for allowing a user to undo instructions several times, reduces the amount of trace data on an instruction that is required for later undoing, and for increasing simulation operability.
2. Description of the Related Art
A simulation system is executed in one of two modes. In one mode, an execution module is read and executed until either the end of the module or a specified breakpoint is reached. In the other mode, a simulation system is started and, after the execution module is read, interaction with a user is executed according to the entered commands.
FIG. 1 is a diagram showing the configuration of a first conventional simulation system which executes simulation interactively. This simulation system comprises an execution module reading module 110 which reads an execution module 100, an initialization module 120 which initializes various variables used for simulation, a command reading module 130 which reads commands entered by an operator, an execution processing module 170 which executes the simulation of the execution module 100 as instructed by a command read by the command reading module 130, and a result outputting module 160 which outputs the result of simulation executed by the execution processing module 170.
When a developed program is executed by a simulation system, the execution module is executed by the simulation system until the end of the module is reached. If, for example, the execution result is not valid or the simulation system runs incorrectly, it is determined that the program has bugs. In this case, the execution module is executed interactively, one or more steps at a time, to determine the cause of the problem.
FIG. 2 is a flowchart showing the processing of the simulation system of FIG. 1. First, the simulation system reads an execution module(step S151) and initializes the variables necessary for simulation(step S152). Then, the system reads a command entered into the system by an operator(step S153). A command entered in this step executes the program until a specified breakpoint is reached, executes the program one step at a time, or ends the program.
In step S154, the system checks if the entered command will execute the program until a breakpoint is reached. If it is, the system repeats the step execution processing S157 until the breakpoint is reached (step S155) and then continues processing according to the next command (step S153). In step S156, the system checks if the entered command will execute the program, one step at a time. If it is, the system executes the step execution processing S157 and then continues processing according to the next command (step S153). In step S158, the system checks if the entered command will end processing. If it is, the system ends simulation processing.
In such a system described above, the user sometimes wants to return control to a location several steps before the current location when control is passed beyond a user-intended location or when an expected result is not obtained after executing several steps. However, the conventional simulation system cannot return control backward. This means that, when such a need arises, simulation must be executed from the beginning. This degrades program development efficiency.
Next, a second conventional simulation system is described. The program explained below saves "trace data", which is the history data on program execution, for use in program debugging. Use of this data allows the simulation system to return control backward through the program. However, the trace data in the conventional system must include various types of data including instruction addresses, registers, memory contents, and flag values.
In addition, for an instruction stored at a particular address, this simulation system saves the "after" value of an operand produced as a result of instruction execution. However, executing the program in the reverse sequence, with only the value of the destination operand (a register or a memory location receiving the result of instruction execution) saved as shown in the examples below, does not restore the value of the operand correctly. In this case, executing the program in the reverse sequence also requires the value of the source operand (a register or a memory location supplying a value for instruction execution) to be saved.
Example 1: Arithmetic instruction
Assume that the program starts with A=4 and B=3. When the result of addition "A+B" is stored in "A", the value of "A" in the conventional trace data is "7" as shown in FIG. 3A. When this instruction is undone and "7" is restored into "A", the source operand "A" is also set to "7". Therefore, re-executing this instruction does not give a correct result. In such a case, not only the destination operand but also the source operand must be saved.
Example 2: Branch instruction
When executing a branch instruction, the conventional trace data saves only the "branch destination" address. Therefore, as shown in FIG. 3B, when an attempt is made to undo the branch instruction after control is passed to address 0x1240, the address from which control has been passed to address 0x1240 is unknown. In such a case, the branch source address must also be saved.
FIG. 4 is a diagram showing the configuration of the second conventional simulation system. This simulation system comprises an execution module reading module 110 which reads an execution module 100, an initialization module 120 which initializes various variables used for simulation, a command reading module 130 which reads commands entered by an operator, an execution processing module 180 which executes the simulation of the execution module 100 as instructed by a command read by the command reading module 130, an UNDO execution processing module 190 which restores trace data on an instruction back to the before-execution state of the instruction as instructed by the command entered from the command reading module 130, and a result outputting module 160 which outputs the result of simulation executed by the execution processing module 180 or by the UNDO execution processing module 190.
The simulation system with the configuration described above must save a large amount of trace data as described above. FIG. 5 shows trace data required for the second conventional simulation system. As shown in the figure, a 358-bit table is required for an instruction because various types of data must be saved including registers, register values, and OP codes ("*" in the figure is a flag indicating whether or not the BNE (Branch Not Equal) instruction caused a branch).
As described above, the first conventional simulation system cannot pass control backward, degrading program development efficiency. The second conventional simulation system requires more trace data as the program size increases, causing a storage capacity problem.
Another method for high-speed simulation is to use a hardware emulator which executes an execution module. However, it is usually difficult for an emulation system to pass control backward.